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FIELD OF THE INVENTION 
10 The present invention relates to a method of 

recording audiovisual content in a communications 
network. 

One particularly advantageous application of the 
invention is the field of remote recording audiovisual 
15 content. 



BACKGROUND OF THE INVENTION 
There are prior art methods for the remote recording 
of audiovisual content broadcast on broadcast channels of 
20 a communications network that consist in requesting a 

broadcast channel to broadcast a content selected by the 
user to a personal digital recorder (PDR) situated in the 
user's home, for example. 

By way of example, users can find it necessary to 
25 use this kind of remote recording method if they are far 
from home and realize that they have forgotten to program 
a recording on a PDR while they were at home. 

Using an office computer, mobile telephone, or 
personal digital assistant (PDA), a user can then program 
30 recording remotely by sending a request to the broadcast 
channel concerned . 

However, although they meet this type of need well, 
the above prior art remote recording methods do not solve 
other problems associated with recording audiovisual 
35 content, in particular if the broadcast channel whose 

content the user would like to record cannot be received, 
for example because that channel is not part of the 
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package to which the user subscribes or because the 
user's receiver can receive only one channel at a time 
and is being used by another person on another broadcast 
channel at the time the content that the user wishes to 
5 record is broadcast. 

Thus the technical problem to be solved by the 
present invention is that of proposing a method of 
recording audiovisual content in a communications network 
that would enable users to record audiovisual content 
10 that they are unable to record directly on their own 

receivers, either because the content cannot be received 
thereby, or because a receiver is not designed to receive 
more than one broadcast channel at a time. 

15 SUMMARY OF THE INVENTION 

In accordance with the present invention, the 
solution to the stated technical problem consists in a 
method of recording audiovisual content in a 
communications network including at least one network 

20 recorder able to record audiovisual content broadcast on 
a plurality of broadcast channels, characterized in that 
said audiovisual content is recorded by a network 
recorder at the request of a user having a communications 
terminal able to exchange information with at least one 

25 network recorder via said communications network, said 
method comprising the following steps: 

• the network recorder declaring itself in the 
network, the declaration indicating at least: 

* a means of access to said recorder, 

30 * a list of broadcast channels whose broadcast 

audiovisual content can be recorded by the network 
recorder, 

the user using a terminal to select a network 
recorder able to record at least one required audiovisual 
35 content and to connect thereto using said access means in 
order to request the recording of said at least one 
audiovisual content, said request including an 
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identification of said at least one audiovisual content 
to be recorded that consists in a unique reference of 
said content and/or an identification of an instance of 
said content consisting of at least the identification of 
5 the broadcast channel of said instance accompanied by the 
indication of a broadcast time band, and 

the network recorder sending a response to the 
user's recording request containing, if the request is 
accepted, an identification of the accepted recording 

10 request for each content to be recorded. 

Accordingly, from a PDR, a personal computer, a 
mobile telephone, or a personal assistant, a user can at 
any time request the network recorder to record an 
audiovisual content on any broadcast channel, even those 

15 channels to which the user does not have direct access, 
in order afterwards to transfer the recorded audiovisual 
content to the receiver of the user's choice (PDR, PC, 
PDA) and to watch it at a time when the receiver is 
available . 

20 One aspect of the invention is a method of declaring 

an audiovisual content network recorder in a 
communications network including at least one network 
recorder able to record audiovisual content broadcast on 
a plurality of broadcast channels, characterized in that 

25 said method comprises at least the step of declaring the 
network recorder in the network, the declaration 
indicating at least: 

* a means of access to said recorder, 

* a list of broadcast channels whose broadcast 
30 audiovisual content can be recorded by the network 

recorder. 

Another aspect of the invention is a method of 
discovering and submitting requests to an audiovisual 
content recorder in a communications network including at 
35 least one network recorder able to record audiovisual 

content broadcast on a plurality of broadcast channels, 
characterized in that said audiovisual content is 
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recorded by a network recorder at the request of a user 
having a communications terminal able to exchange 
information with at least one network recorder via said 
communications network, said method comprising the 
5 following steps: 

• using the terminal to select a network recorder 
able to record at least a required audiovisual content 
and connecting thereto using a means of access to said 
recorder in order to request the recording of said at 

10 least one audiovisual content, said request including an 
identification of said at least one audiovisual content 
to be recorded that consists in a unique reference of 
said content and/or an identification of an instance of 
said content consisting of at least the identification of 

15 the broadcast channel of said instance accompanied by the 
indication of a broadcast time band, and 

• receiving a response to the user's recording 
request sent by the recorder and containing, if the 
request is accepted, an identification of the accepted 

20 recording request for each content to be recorded. 

According to the invention, said time band 
indication includes the broadcast start time and either 
the broadcast end time or the duration of the broadcast 
on the broadcast channel of said instance. 

25 The invention further consists in a method of 

recording audiovisual content in a communications 
network. The recording method comprises the following 
steps : 

• connecting to said terminal a network recorder 

30 able to record at least one required audiovisual content 
selected by said terminal using a means of access to said 
recorder to request the recording of said at least one 
audiovisual content, said request including an 
identification of said at least one audiovisual content 

35 to be recorded that consists in a unique reference of 

said content and/or an identification of an instance of 
said content consisting of at least the identification of 
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the broadcast channel of said instance accompanied by the 
indication of a broadcast time band, and 

• sending a response to the user's recording request' 
containing, if the request is accepted, an identification 

5 of the accepted recording request for each content to be 
recorded. 

When it has received a recording request, the 
network recorder sends a response to the user who sent 
the request • 

10 If the request is accepted, the invention envisages 

a number of options in addition to identification of the 
accepted request, namely: the response from the network 
recorder contains said unique reference of the requested 
audiovisual content, the response from the network 

15 recorder contains the programmed end of recording time 
and/or the cost of said recording, or the response from 
the network recorder contains the time for which the 
network recorder will keep the recording. 

The discovery and request submission method of the 

20 invention also offers the user the option to review and 
revise a request, by said method further including the 
steps of the user formulating a request to cancel a 
recording request that has been accepted or to delete a 
content that has been recorded by the network recorder, 

25 that request specifying at least the identification of 
the recording request that has been accepted. 

To enable the user to determine at any time the 
stage reached by the network recorder in processing a 
request, the discovery and request submission method and 

30 the recording method of the invention also include the 
steps of: 

• if the request is accepted, the network recorder 
receiving from the terminal a recording request status 
request indicating at least said identification of the 

35 accepted recording request, and 

• the network recorder sending a response to the 
recording request status request containing at least the 
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identification of the accepted recording request and the 
status of the request. 

Said recording request status request preferably 
contains said unique reference of the content and/or the 
5 identification of the user. 

The response of the recorder to the recording 
request status request may take various forms, depending 
on the situation: 

• in the case of a request that has not yet been 
10 executed, the response to the recording request status 

request contains the unique reference of the content 
and/or the programmed end date and time, 

• in the event of an unknown request, the response 
to the recording request status request contains the 

15 unique reference of the content, 

• in the event of failure of the request, the 
response to the recording request status request contains 
the unique reference of the content, 

• if the content is available, the response to the 
20 recording request status request contains an address at 

which the recorded content is available. In which case, 
the response contains the unique reference of the content 
and/or the time for which the network recorder will keep 
the recording. 

25 One aspect of the invention is a device for 

declaring a network recorder of audiovisual content in a 
communications network including at least one network 
recorder able to record audiovisual content broadcast on 
a plurality of broadcast channels, characterized in that 

30 said declaration device comprises at least: 

• means for generating a declaration indicating at 
least : 

• a means of access to said recorder, 

• a list of broadcast channels whose broadcast 
35 audiovisual content can be recorded by the network 

recorder, and 
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' means for sending said declaration of the network 
recorder into the network. 

One aspect of the invention is a device for 
recording audiovisual content in a communications network 
5 including at least one network recorder able to record 

audiovisual content broadcast on a plurality of broadcast 
channels, characterized in that said audiovisual content 
is recorded by a network recorder at the request of a 
user having a communications terminal able to exchange 
10 information with at least one network recorder via said 
communications network, said recording device including: 

• means for connecting to said terminal a network 
recorder able to record at least one required audiovisual 
content selected by said terminal using a means of access 

15 to said recorder in order to request the recording of 
said at least one audiovisual content, said request 
including an identification of said at least one 
audiovisual content to be recorded that consists in a 
unique reference of said content and/or an identification 

20 of an instance of said content consisting of at least the 
identification of the broadcast channel of said instance 
accompanied by the indication of a broadcast time band, 
and 

• means for sending a response to the user's 

25 recording request containing, if the request is accepted, 
an identification of the accepted recording request for 
each content to be recorded. 

Another aspect of the invention is a network 
recorder able to record audiovisual content in a 

30 communications network including at least one network 

recorder able to record audiovisual content broadcast on 
a plurality of broadcast channels, characterized in that 
said audiovisual content is recorded by a network 
recorder at the request of a user having a communications 

35 terminal able to exchange information with at least one 
network recorder via said communications network, said 
network recorder including: 
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• means for connecting to said terminal a network 
recorder able to record at least one required audiovisual 
content selected by said terminal using a means of access 
to said recorder in order to request the recording of 

5 said at least one audiovisual content, said request 
including an identification of said at least one 
audiovisual content to be recorded that consists in a 
unique reference of said content and/or an identification 
of an instance of said content consisting of at least the 
10 identification of the broadcast channel of said instance 
accompanied by the indication of a broadcast time band, 
and 

• means for sending a response to the user's 
recording request containing, if the request is accepted, 

15 an identification of the accepted recording request for 
each content to be recorded. 

The invention also consists in a device for 
discovering and submitting requests to a recorder of 
audiovisual content in a communications network including 

20 at least one network recorder able to record audiovisual 
content broadcast on a plurality of broadcast channels, 
characterized in that said audiovisual content is 
recorded by a network recorder at the request of a user 
having a communications terminal able to exchange 

25 information with at least one network recorder via said 
communications network, said discovery and request 
submission device including: 

• means for choosing by means of the terminal a 
network recorder able to record at least one required 

30 audiovisual content and for connecting thereto using a 

means of access to said recorder in order to request the 
recording of said at least one audiovisual content, said 
request including an identification of said at least one 
audiovisual content to be recorded that consists in a 

35 unique reference of said content and/or an identification 
of an instance of said content consisting of at least the 
identification of the broadcast channel of said instance 
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accompanied by the indication of a broadcast time band^ 
and 

• means for receiving a response to the user's 
recording request sent by the recorder containing, if the 

5 request is accepted, an identification of the accepted 
recording request for each content to be recorded. 

One aspect of the invention is a communications 
terminal in a communications network including at least 
one network recorder able to record audiovisual content 

10 broadcast on a plurality of broadcast channels, 

characterized in that said audiovisual content is 
recorded by a network recorder at the request of a user 
having said communications terminal able to exchange 
information with at least one network recorder via said 

15 communications network, said terminal including: 

' means for choosing by means of the terminal a 
network recorder able to record at least one required 
audiovisual content and for connecting thereto using a 
means of access to said recorder in order to request the 

20 recording of said at least one audiovisual content, said 
request including an identification of said at least one 
audiovisual content to be recorded that consists in a 
unique reference of said content and/or an identification 
of an instance of said content consisting of at least the 

25 identification of the broadcast channel of said instance 
accompanied by the indication of a broadcast time band, 
and 

• means for receiving a response to the user's 
recording request sent by the recorder containing, if the 

30 request is accepted, an identification of the accepted 
recording request for each content to be recorded. 

BRIEF DESCRIPTION OF THE DRAWINGS 
The following description with reference to the 
35 appended drawings, which are provided by way of 

non-limiting example, explains in what the invention 
consists and how it may be reduced to practice. 
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Figure 1 is a general flowchart of the recording 
method of the invention. 

Figure 2 is a flowchart of the recording method of 
the invention in the case of a successful recording 
5 request. 

Figure 3 is a flowchart of the recording method of 
the invention in the case of a failed recording request. 

Figure 4 is a flowchart of the recording method of 
the invention in the case of a successful recording 
10 request with additional time-delay. 

Figure 5 is a flowchart of the recording method of 
the invention in the case of a successful recording 
request followed by a cancellation request. 

Figure 6 is a flowchart of the recording method of 
15 the invention in the case of a successful recording 
request followed by a failure to record. 

Figure 7 is a flowchart of the recording method of 
the invention in the case of an unknown recording 
request . 

20 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
Figure 1 is a general flowchart of a method of 
recording audiovisual (AV) content in a communications 
network . 

25 That method involves at least one network recorder, 

corresponding to the right-hand portion of Figure 1, able 
to record audiovisual content broadcast on broadcast 
channels. Network recorder operators offer a user the 
service of recording on their behalf audiovisual content 

30 that they are unable . to record themselves, for example 

because this is not possible as the user does not have an 
appropriate subscription or does not have access to the 
broadcast channel that is broadcasting the required AV 
content or because their receiver is already being used 

35 by another person on another broadcast channel. Network 
recorders can be provided by operators specializing in 
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this type of service or by the broadcast channels 
(television channels) themselves. 

The network recorder records an audiovisual content 
at the request of a user, corresponding to the left-hand 
5 portion of Figure 1, provided with a terminal able to 
exchange information concerning recording requests with 
network recorders via a communications network. 

Initially, the network recorders must declare 
themselves on the communications network, either directly 

10 through a recorder website or indirectly via a directory, 
for example a UDDI (Universal Description Discovery and 
Integration) directory associated with the SOAP (Simple 
Object Access Protocol) exchange technology. In which 
case, the directory has to create a particular ^^Network 

15 Recorders" heading and list in the directory under that 
heading the network recorders that have been declared. 

The declaration of the existence each network 
recorder in the network ( <ry_Kecord_Service_/:)eciara tion> 
data structure) indicates: 

20 • preferably, an address of the network recorder 

(<RecordServiceAddress> element), which is the address to 
which the recording request must be sent, and is either 
the address of a website or the address of a directory 
heading, 

25 • preferably, a list of the broadcast channels that 

it can record (<DeliveryServiceList> element), able to 
contain for each channel: 

* preferably, the address of the broadcast 
channel ("serviceURL" attribute), for example as defined 

30 by the TV Anytime forum, 

* optionally, the charging policy of the 
recorder for that broadcast channel (<ChargingPolicy> 
element) , 

• optionally, the conversion capabilities of the 
35 recorder {<ConversionCapabilities> element) consisting 
of: 
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* the bit rate reduction capability 
(<BitrateConversionCapability> element), for example bit 
rate reduction from 4 Mbps to 2 Mbps, 

* the ability to transcode the audiovisual 

5 content {<TranscodingCapability> element) into different 
audiovisual coding formats, such as MPEG2 to MPEG4 
transcoding, 

* optionally, the protocols supported for 
transferring the recorded AV content to the user's 

10 receiver: FTP, streaming, or downloading. 

Thus the invention provides two main ways to access 
a network recorder. One way to access a network recorder 
is to use an address of said recorder in the network. 
The other way is to use a directory listing the 

15 operations specific to the network recorders, each 

network recorder being identified by said operation. 

More precisely, according to the invention, said 
list of broadcast channels whose broadcast audiovisual 
content can be recorded by the network recorder includes 

20 the address of each broadcast channel, optionally 
accompanied by the charging policy of the network 
recorder for each broadcast channel. The broadcast 
channel address is a channel identifier codified by a 
consortium combining interested companies and 

25 organizations, such as the TV Anytime forum. 

To enable the user to receive the audiovisual 
content recorded by the network recorder subject to 
technical conditions compatible with the user's receiver, 
the invention provides for the declaration of the network 

30 recorder in the network to contain the conversion 
capabilities of said recorder, which relate more 
particularly to bit rate reduction and/or transcoding of 
the audiovisual content. 

It should also be pointed out that the bit rate and 

35 transcoding constraints in respect of the audiovisual 
content emanate from the user, since the invention 
teaches that said request should contain the conversion 
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capabilities required by the user for transferring the 
recording to the user's terminal. 

The user must be in a position to discover the 
existence of network recorders in order to be able to 
5 select the one able to record the required AV content 
under the best technical, economic and ergonomic 
conditions. This can be done: 

• either by defining a particular MIME (Multipurpose 
Internet Mail Extensions) type (e.g. "application/x-TV- 

10 Record-Service-Declaration") , which, when a file of this 
type is received from a website, activates software on 
the user's receiver for interpreting the 
<TV_Record_Service_Declaration> data structure defined 
above, 

15 • or by using a UDDI directory and defining a new 

"tModel" for AV content recording services enabling any 
recorder to declare its existence and its capabilities to 
the directory in the <TV_Record_Service_Declaration> data 
structure defined above. 

20 Having selected the best-suited network recorder for 

recording the required AV content from a website or a 
directory, the user sends that recorder a recording 
request {<TV_Record_Service_Request> data structure) 
comprising : 

25 • preferably, the identification of the user 

(<UserId> attribute) if the user has not been identified 
some other way, for example at the time of connecting to 
the recorder (log in and password type connection), 

• preferably, an identification of the AV content to 
30 be recorded, which may be: 

* either a unique reference of said content 
("GRID" attribute), essentially a simple identification 
of the content as such, 

* or the user's own identification of an 
35 instance of that content consisting of: 

• preferably, the identification of the 
broadcast channel ( "serviceURL" attribute). 
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• preferably, the start- time ("start" 

attribute) , 

• preferably, the end time ("end" 
attribute) or the duration ("duration" attribute), 

5 • optionally, the identification of a 

particular instance {"instanceMetadatald" attribute), 

• optionally, the conversion capabilities required 
by the user. 

The network recorder's response to the user's 
10 recording request ( <TV^Record_Service_Request_Response> 
data structure) contains for each content to be recorded 
an indication : 

• either of the success of the recording request 
(<RecordRequestSuccess> element), this indication 

15 containing: 

* preferably, the identification of the 
accepted recording request {"requestid" attribute), 

* optionally, the identification of the 
requested content ("GRID" attribute), 

20 * optionally, the programmed end of recording 

time ( "recordEndTime" attribute), 

* optionally, the time to keep the recorded 
content ( "keepDuration" attribute), 

* optionally, the cost of the recording 
25 {"recordCost" and "currency" attributes), 

• or of the failure of the recording request 
{<RecordRequestFailure> element), this indication 
containing : 

* preferably, the identification of the 
30 requested content {"GRID" attribute), 

* optionally, the reason for failure of the 
request {"KOreason" attribute). 

If a recording request from the user fails, the 
response of the network recorder to the request contains 
35 an identification of content concerned if a plurality of 
contents was requested. Similarly, the response from the 
recorder contains the reason for the failure of the 
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request. A request may fail because the network recorder 
does not have access to the content requested by the 
user, for example. 

If a recording request is accepted, its status can 
5 be requested (<TV_Record_Request_Status_Request> data 
structure), the request indicating: 

• preferably, the identification of the accepted 
recording request {"requestid" attribute), 

• optionally, the identification of the content to 
10 be recorded {"GRID" attribute), 

• optionally, the identification of the user 
(<UserId> attribute) . 

On receiving a request status request, the network 
recorder sends a response 
15 {<TV_Record_Request_Status_^Response> data structure) 
containing : 

• in the case of a request that has not yet been 
executed: 

* preferably, the identification of the 
20 accepted recording request ("requestid" attribute), 

* preferably, the status of the request 
("status" attribute, "runnningRequest" value), 

* optionally, the identification of the 
content to be recorded ("GRID" attribute), 

25 * optionally, the programmed end date and 

time ( "callAfter" attribute) , 

• in the case of an unknown request (« requestID » 
attribute not recognized) : 

* preferably, the identification of 
30 the accepted recording request {"requestid" attribute), 

* preferably, the status of the request 
("status" attribute, "unknownRequest" value), 

* optionally, the identification of the content 
to be recorded ("GRID" attribute), 

35 • in the case of a request that fails (for example 

in the event of an equipment failure) : 
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* preferably, the identification of the 
accepted recording request ( "request Id" attribute), 

* preferably, the status of the request 
("status" attribute, "failedRequest" value), 

5 * optionally, the identification of the content 

to be recorded {"GRID" attribute), 

' in the case of a request that has been completed 
with the recorded content available: 

* preferably, the identification of the 
10 accepted recording request ("requestid" attribute), 

* preferably, the status of the request 
("status" attribute, "contentAvaiiajbie" value), 

* preferably, the means of recovering the 
recorded content ( "con tent C/RL" attribute), 

15 * optionally, the identification of the content 

to be recorded ("GRID" attribute), 

* optionally, the time for which the recorder 
will keep the recorded content ( "iceepDura tion " 
attribute) . 

20 The user can also request cancellation of a 

recording request ( <rv_Kecord_i^egues t_Cance2> data 
structure), for example if the user changes his or her 
mind, the cancellation request indicating: 

• preferably, the identification of the accepted 
25 recording request ( "reguestid" attribute) , 

• optionally, the identification of the content to 
be recorded {"GRID" attribute), 

• optionally, the identification of the user 
{<C7serId> attribute) . 

30 The user can also request the deletion of an AV 

content that has already been recorded in the network 
(<Recorded_Gontent_Delete> data structure), the deletion 
request indicating : 

• preferably, the identification of the accepted 
35 recording request {"requestid" attribute), 

• optionally, the identification of the content to 
be recorded ("GRID" attribute). 
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• optionally, the identification of the user 
(<UserId> attribute) . 

The steps of the recording method that have just 
been generally described with reference to Figure 1 will 
5 now be described in more detail with reference to Figures 
2 to 7. 

1. Recording audiovisual content in the network from a 
network recorder website. 

1.1. Discovering a network recorder website. 
10 An audiovisual content recorder can make itself 

known by means of an HTML page on a website. 

On clicking on a link indicated on the web page, the 
user's terminal receives a file of a particular MIME 
type : applies tion/x-TV-Record-Service-Declaration" . 
15 This file contains the following information: 

• preferably, the address of the recorder on the 
network [<RecordServiceAddress> element), 

• preferably, a list of the channels that it can 
record (<DeliveryServiceList> element) containing for 

20 each channel: 

* preferably, the address of the channel as 
defined by the TV Anytime forum ( "serviceC/i^L " attribute), 

* optionally, the charging policy of the 
recorder for that channel {<ChargingPolicy> element), 

25 • optionally, the conversion capabilities of the 

recorder {<ConversionCapabilities> element), consisting 
of: 

* a bit rate reduction capability 
(<BitrateConversionCapability> element) , 

30 * an audiovisual content transcoding capability 

[<TranscodingCapability> element) relating to transcoding 
a content into different audiovisual coding formats, 

• optionally, the protocols supported for 
transferring the recorded content to the user's terminal 

35 (e.g. only the FTP mode or another mode is always 
proposed by default) . 
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In one variant of the invention, the declaration of 
the network recorder in the network contains the 
protocols that the network recorder can use to transfer 
the recorded audiovisual content to the user's terminal. 
5 In other words, this enables the user to choose either a 
direct streaming transfer mode or a downloading mode 
(off-line relative to recording the content in the 
network) , 

There follows an example of a file declaring a 
10 recorder in the network: 

<TV_Record_Service_Declaration xmtns:xsi="http://www.w3.org/2001/XMLSchema-instance*' 
xsiinoNamespaceSchemaLocationsTVRecServ.xsd" version="1''> 

<RecordServiceAddress>http:/^Avw.voila.fr/RecordRequest.rr</Rea)rdServic^ 
<ConversionCapabilities> 

<BitrateConversionCapability>true</BitrateConversionCapability> 
<TranscodlngCapabllity>MPEG-1 </T ranscodlngCapability> 
<TranscodingCapability>MPEG-4</TranscodingCapability> 
</ConversionCapabilities> 
<SupportedTransferProtocols> 

<SupportedTransferProtocx>l value=*'FTP7> 
<SupportedTransferProtocol value=''HTTP7> 
</SupportedTransferProtocols> 
<DeliveryServiceList> 

<DeliveryService serviceURL="dvb://1 .2.a"> 

<ChargingPolicy xml:lang="en">3 USD for AV contents produced In the last 3 months. 1 USD for 
the other contents</ChargingPollcy> 
</DeliveryService> 

<De!iveryService serviceURL="dvb://1 .2.b"/> 
<DeliveryServlce serviceURL="dvb://1 .2.c"/> 
</DellveryServlceLlst> 
</TV_Record_Servlce_Declaratlon> 

This table is used to declare a broadcast 
35 audiovisual content recorder to which requests may be 
submitted at the address indicated by the 
<RecordServiceAddress> element for content delivery 



15 



20 



25 



30 
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services or broadcast channels (television channels) 
indicated by the <DeiiveryService{7iRL> elements. 

Accordingly, if the user wishes to record a content 
broadcast by one of the broadcast channels declared in 
5 this way, if the user' s terminal does not receive the 

channel broadcasting the selected content directly or is 
unable to receive it at the time the content is 
broadcast, it can request the recording of that content 
at the address indicated in the <RecordServiceAddress> 
10 element. 

1.2. Requesting by the user of recording in the 
network. 

When a user has discovered in the preceding step 
that a network recorder is able to record audiovisual 

15 content broadcast by a particular broadcast channel and 
the user wishes to activate a network recorder, the user 
must send it the request <TV_Record_Service_Request>, at 
the address indicated by the <RecordServiceAddress> 
element of the above table, with the following 

20 information: 

• preferably, the identification of the user 
( "Userld" attribute) , 

• optionally, the identification of the protocol to 
be used to transfer the content after recording, 

25 • optionally, the identification of the coding 

required for the content to be recorded (which may call 
for transcoding in the recorder) , 

• preferably, the identification of the content to 
be recorded {"GRID" attribute), 

30 • optionally, the identification of an instance of 

that content consisting of: 

* preferably, the identification of the 
television channel { "serviceURL" attribute), 

* preferably, the start time ("start" 
35 attribute) , 

* preferably, the end time ( "end" attribute) or 
the duration {"duration" attribute). 
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* optionally, the identity of a particular 
instance { "instanceMetadatald" attribute). 

There follows an example of a file requesting 
recording in the network of two contents using FTP as the 
5 recorded content recovery protocol and transcoding to 
MPEG-4 with a maximum bit rate of 1500 kbps for the 
"crid: //hbc. com/f oxes/episodell" content on the 
television channel "dvb:// 1.4ee2.3f5/" and the 
"crid: //chl . com/serie/epl2" content on the channel 
10 "dvb://1.4ee2.3f4;4f5/" : 

<TV_Record_Service_Request xmlns:xsl="http://wvw.w3.org/2001/XMLSchema-instance" 
xsi:noNamespaceSchemaLocation=TVRecServ.xsd" userld="X3YZDFdeGH49"> 
<RequestedTransferProtocol>FTP</RequestedTransferProtocol> 
<Transcoding>MPEG-4<yTranscoding> 
<MaxBitRate>1 500</MaxBitRate> 

<Contentldentification crid="crid://hbc.com/f6xes/episodeir serviceURL="dvb:// 1.4ee2.3f5/" start="2001- 
04-07X19:00:00.00+01 :00" duration=TT1 H30M7> 

<Contentldentification crid='*crid://ch1 .com/serie/ep12" serviceURL="dvb://1.4ee2.3f4;4f5r start="2003-06- 
27712:30:00.00+01 :00" duratjon=TT0H30M" instanceMetadatald="lmi:broadcast/17> 
</TV_Recx)rd_Service_Request> 

Each content to be recorded is identified by its 
CRID, the serviceURL that will deliver the content, its 
25 start time and its duration (or its end time), and where 
applicable its instance identification. 

The response <TV__Record_Service_Request_Response> 
received in return indicates for each content whose 
recording has been requested: 
30 ' either the success of the recording request 

(<RecordRequestSuccess> element) (Figure 2), giving: 

* preferably, the identification of the 
accepted recording request ( "reguestid" attribute), 

* preferably, the identification of the 

35 requested content {"CRID" attribute) , if a plurality of 
contents was requested in the same request, 



15 



20 
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* optionally, the identification of the 
requested content ( "CJRID "attribute ) , if a single content 
was requested, 

* optionally, the progranmied end of recording 
5 time {"recordEndTime" attribute), 

* optionally, the time to keep the recorded 
content ( "keepDuration" attribute), 

* optionally, the recording cost recordCost" 
and "currency" attributes), 

10 ' or the failure of the recording request 

(<RecordRequestFailure> element) (Figure 3), giving: 

* preferably, the identification of the content 
for which the request has failed {"CRID" attribute), if a 
plurality of contents was requested in the same request, 

15 * optionally, the identification of the 

requested content {"CRID" attribute), if a single content 
was requested, 

* optionally, the reason for failure of the 
request {"KOreason" attribute). 

20 There follows an example of a response to a 

recording request with success for two contents (the time 
to keep and the cost to be paid the being indicated for 
the second one) and failure for two others: 



2 5 <TV_Record_Service_Request_Response xmlns:xsi="http:/Awww. w3.org/2001/XMLSchema-instance" 

xsi:noNamespaceSchemaLocation="TVRecServ.xsd"> 

<RecordRequestSuccess crid="crid://hbc.com/f6xes/episode11" requestld="12456XD34" 
recordEndTime="2003-04-07T20:30:00.00+01:007> 

<RecordRequestSuccess crid="crid://zzz.com/movle/titler requestld="156WQ77" recordEndTime="2003-04- 

3 0 07120:30:00.00+01 :00" keepDuration="PT24H" recordCost="2" currency="USD"/^ 

<RecordRequestFailure crid="crid://ch1 .com/seiie/ep12" KOreason="unknownCRID''/> 
<RecordRequestFailure crid="crid://chaine5.com/fllm 1 5" KOreason="unavallableServlceURL7> 
</TV_Record_Service_Request_Response> 



35 1.3. Management of a request for recording in the 

network. 
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After accepting a request for recording in the 
network, the network recorder is able to monitor changes 
in the scheduling of the broadcasting of AV contents and 
to reprogram the recording of the requested contents 
5 accordingly. 

After a request for recording in the network is 
accepted, the user has a number of options: 

• to cancel the recording request (if the cost is 
too high or the user changes his or her mind) , 

10 • to track the status of a recording request (to 

find out if the content has been reprogrammed at another 
date or time, or if the recording is finished) . 

To cancel a recording request, the user must send a 
recording request cancellation request 

15 (<TV_Record_Request_Cancel> date structure) (Figure 5) 
containing : 

• preferably, the identification of the accepted 
recording request ( "requestid" attribute) , 

• optionally, the identification of the content to 
2 0 be recorded ("GRID" attribute), 

' optionally, the identification of the user 
(<UserId> attribute) . 

There follows an example of a recording request 
cancellation request: 

25 

<TV_Record_Request_Cancel xmlns:xsi="http://vvww.w3.org/2001/XMLSchema-instance'' 
xsi:noNamespaceSchemaLocation="TVRecServ.xsd" crid=''crid://hbc.com/foxes/episode1 1 " 
requestld="1 2456XD347> 

30 No response is expected from the recorder. 

To track the status of a recording request, the user 

must send a recording request status request 

(<TV_Record_Request_Status_Request> data structure) 

(Figure 2) containing: 
35 • preferably, the identification of the accepted 

recording request { "requestid" attribute) , 
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• optionally, the identification of the content to 
be recorded {"GRID" attribute), 

• optionally, the identification of the user 
(<UserId> attribute). 

5 There follows an example of a "recording status 

request" request: 

<TV_Record_Request_Status_Requestxmlns:xsi="http://wvw.w3.org/20^ 
xsiinoNamespaceSchemaLocationsTVRecServ.xsd" crid="crid://hbc.com/foxes/episodeir 
1 0 requestld="12456XD347> 

Several responses are possible. If the content has 
not yet been recorded (Figure 4), the response from the 
recorder includes: 
15 • preferably, the identification of the accepted 

recording request ("requestid" attribute), 

• preferably, the status of the request ("status" 
attribute, "runnningRequest" value), 

• optionally, the identification of the content to 
20 be recorded {"GRID" attribute), 

• optionally, the programmed end date and time 
("callAfter" attribute). 

There follows an example of a "content not yet 
recorded" response : 

25 

<TV_Re(X)rd_Request_Status_Responsexmlns:xsi="http://wvw.w3.org/2001/XMLSchOT 
xsknoNamespaceSchemaLocatlonsTVRecServ.xsd" crid="crid://hbc.com/foxes/episode1 1 " 
requestld=''1 2456X034" status="ajnningRequesr ="2003-06-27T14:30:00.00+01:007> 

30 The "callAfter" attribute enables the terminal to 

program a timer for repeating a recording status request 
if there is any chance of obtaining a different response. 
This is the case if the broadcast time of a content has 
changed . 

35 If the request is not recognized as valid (Figure 

7), the response from the recorder includes: 
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• preferably, the identification of the accepted 
recording request { "regues tid" attribute), 

• preferably, the status of the request ("status" 
attribute, "unknownRequest" value), 

5 • optionally, the identification of the content to 

be recorded {"GRID" attribute). 

There follows an example of an "unknown recording 
request " response : 

1 0 <TV_Record_RequesLStatus_Response xmlns:xsl="http://www.w3.org/2001/XMLSchema-instance" 
xsi:noNamespaceSchemaLocation="TVRecServ.xsd" crid='*crid://hbc.com/foxes/episode1 1 " 
requestld="12456XD34" slatus="unknownRequest7> 

This situation can arise if the user's terminal 
15 interrogates the network recorder after the end date for 
keeping a recorded content. 

If the request has failed (Figure 6), the recorder 
responds with: 

• preferably, the identification of the accepted 
20 recording request ( "requestid" attribute) , 

• preferably, the status of the request ("status" 
attribute, "failedRequest" value) , 

• optionally, the identification of the content to 
be recorded ("GRID" attribute). 

25 There follows an example of a "failed recording 

request" response : 

<TV_Record_Request_Status_Response xmlns:xsi="http://wwv.w3.org/2001/XMLSchema-instance" 
xsiinoNamespaceSchemaLocatlonsTVRecServ.xsd" crid="crid://hbc.com/foxes/episode1 1 " 
3 0 requesttd^^l 2456X034" status="failedRequest7> 

If recording has finished and the content is 
available, the response from the recorder includes: 

• preferably, the identification of the accepted 
35 recording request {"reqvestid" attribute), 

• preferably, the status of the request ("status" 
attribute, "contentAvailable" value). 
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• optionally, the identification of the content to 
be recorded ("GRID" attribute), 

• optionally, the time to keep the recorded content 
in the recorder ( "keepDuration" attribute), 

5 • preferably, the means of recovering the recorded 

content ("contentURL" attribute). 

There follows an example of a "recorded content 
available in the recorder" response: 

1 0 <TV_Record_Request_Status_Response xmlns:xsi="http://www.w3.org/2001 /XMLSchema-instance" 
xsi:noNamespaceSchenriaLocation="TVRecServ.xsd" crid="crid://hbc.com/foxes/episode1 1 " 
requestld="1 2456XD34" status="contentAvailable" 
contentU RL=''ftp://login:password@ftp.tvrs .fr/user1 /avi 2 .m pg7> 

15 1.4 Transferring and deleting a content recorded in 

the network. 

If the recorder responds to a content recording 
request status request by indicating that the content is 
available, the user's terminal can then download the 
20 content, the address of the content being indicated by 
the <contentURL> attribute of the response from the 
recorder . 

The recording will be deleted automatically after a 
certain time or in response to a specific request from 
25 the terminal containing: 

• preferably, the identification of the accepted 
recording request ("requestid" attribute), 

• optionally, the identification of the content to 
be recorded {"GRID" attribute), 

30 • optionally, the identification of the user 

(<UserId> attribute) . 

There follows an example of a request to delete a 
recording : 

3 5 <Recorded_Content_Delete xmlns:xsi="http://wwv.w3.org/2001/XMLSchema-instance" 

xsi:noNamespaceSchemaLocation="TVRecServ.xsd" crid="crid7/hbc.com/foxes/eplsode1 1 " 
requestld=''12456XD347> 
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No response is expected from the recorder. 
2. Recording of an audiovisual content by a network 
recorder using UDDI and SOAP. 
5 2.1 Declaring the network recorder using UDDI (web 

service) . 

The technology of web services and in particular of 
UDDI (Universal Description, Discovery and Integration) 
services enables recorders of audiovisual content 
10 broadcast in the network by broadcast channels to be 
entered into a directory: the UDDI directory. 

The SOAP (Simple Object Access Protocol) technology 
is used to exchange XML-type data structures . 

It must be possible to record in the UDDI directory: 
15 • a new service category (or heading) : the service 

for recording audiovisual content in the network with its 
access point and the operations accepted from users' 
terminals, 

• a search criterion: the identifier of each 

20 broadcast channel (television channel) . 

Thus a user terminal looking for a network recorder 
can consult the directory, supplying one or more 
broadcast channel (television channel) identifiers and 
requesting in return a means of addressing directly 

25 recorders that satisfy the search criteria. 

The new search criterion in the UDDI directory that 
consists of the television channel identifier, for 
example, must be the subject of the definition of a new 
UDDI tModel, here called "serviceURL" (in conformance 

30 with section 1.6.4 of the UDDI specifications relating to 
the definition of "tModel"), to declare the audiovisual 
content broadcast channels. It is given the name "tv- 
record-org: serviceURL" . This is an authority that must 
request the recording of this new "tModel". The entity 

35 "tv-record-org" is any entity, for example "tv-anyti/ne- 
org". This leads to declaring a key with the same name 
"uddi : t V- record . org : servi ceURL " . 
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The declaration of that key also includes references 
to the specifications of this "tModel" by the 
organization requesting its insertion 
"<overviewDoc><overviewURL>" and the "<categoryBag>'' 
5 element contains standard information included in any 
"tModel" declaration . 

<tModel tModelKey="uddi:tv-record.org:servlceURL"> 
<name>tv-record-org:serviceURL</name> 

<description xml:lang="en''>Category system for each delivery service handled by a recording 
service</descriptlon> 
<overviewDoc> 

<overviewURL useType="text"> 

ftp://pub:pub@ftp.francetelecom.fr/pub/Spec/Record_tlVlodel.zip 
</overviewURL> 
</overviewDoc> 
<categoryBag> 
<l<eyedReference keyName="uddi-org:types:categorization" 
keyValue="categorization" tModelKey=''uddi:uddi.org:categorization:types7> 

<keyed Reference keyName="uddi-org:types:unchecked" 
keyValue=''unchecked" tModelKey="uddi:uddi.org:categorization:types7> 
</categoryBag> 
</tModel> 

It is also necessary to define a ^'tModel port" for 
sending requests to the audiovisual content recorder as 
follows: this "tModel'' describes the service for 
transferring "submit_Data" requests to the content 
recorder in the network, the use of which will be 
illustrated later: 

<tl\1odel tModelKey="uddi:tv-record.org:submit_Data_v1 0"> 
<name>tv-record-org:subm it_Data_v1 0</name> 

<description xml:lang="en">TV Record WSDL interface for submit_Data port</description> 
3 5 <overviewDoc> 

<overviewURL useType="wsdllnterface"> 

http://vyww.tv-record.Org/wsdl/tvr_transport_v10.wsdl#submit_Data_SOAP 
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</overvlewURL> 
</overviewDoc> 
<overviewDoc> 

<overviewURL useType=''text''> 
5 ftp://tvr:tvr@ftp.voila,fr/spec/tvr_xxV10.zip 

</overviewURL> 
</overviewDoc> 
<categoryBag> 

<keyedReference keyName="uddi-org:typeswsdr keyValue="wsdlSpec" 
1 0 tMcxjelKey=*'uddi:uddi.org:categorization:types7> 

<keyedReference keyName="uddi-org:types:soap" keyValue="soapSpec" 
tModelKey="uddi:uddt.org:categorization:types7> 
<keyedReference keyName=''uddi-org:types:xmr keyVa!ue="xmlSpec" 
tModelKey="uddi:uddi.org:categorization:types7> 
1 5 <keyedReference keyName="uddi-OFg:types:5pecification'' 

keyVatue="specification" tModelKey="uddi:uddi.org:categorization:types7> 
</categoryBag> 
</tModel> 

20 To make itself known, a broadcast audiovisual 

content recorder must declare its recording capabilities 
using the "save_binding" method (see the UDDI API 
publication) , assuming that the appropriate parental 
structures "husinessEntity" and "businessService" have 

25 already been declared, referring to the ''tModel'' defined 
previously: 

<save_binding xmlns=''um:uddi-org:apl_v3"> 
<bindingTemplate> 

3 0 <description xml:lang=''fr">Declaration of an audiovisual content recording service for one or more 

television channels </description> 
<accessPoint useType="endPoint"> 

http://www.voila.fr/movles 
</accessPoint> 
3 5 <tModeltnstanceDetails> 

<tModellnstancelnfotModelKey="uddi:tv-record.org:submit_Data_v10"> 
<instanceDetaits> 
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<instanceParms><![CDATA[ 

<?xm! version=''1.0'' encoding="utf-8"?> 
<describe_submit_Data_Result service Version="3" 

xmlns="http://www.tv-anytime.org/2002/11/transport''> 
5 <ConversionCapabilitjes> 

<BitrateConversionCapabiIity>true</BitrateConversionCapability> 
<TranscodingCapability>MPEG-1</TranscodlngCapability> 
<TranscodingCapability>MPEG-4</TransoodingCapability> 
</ConversionCapabilities> 
1 0 <SupportedTransferProtocols> 

<SupportedTransferProtocol value="FTP7> 
<SupportedTransferProtocol value="HTTP7> 
</SupportedTransferProtocols> 
<DeliverySery/iceLtst> 
1 5 <DeliveryService servlceURL="dvb://1 .2.a"> 

<ChargingPolicy xml:lang=''en">3 USD for AV contents produced in the last 3 months, 1 USD for the other 
contents</ChargingPolicy> 
</DeliveryService> 

<DeliveryService serviceURL="dvb://1 .2.b7> 
2 0 <De!iveryService serviceURL=''dvb://1 .2.c7> 
</DeliveryServiceList> 

</desGribe_submit_Data_Result> 
]]></instancePan7>s> 
</instanceDetails> 

2 5 </tModeIlnstanceInfo> 

</tModellnstanceDetails> 
<categoryBag> 

<keyedReference tModelKey="uddi:tv-record.org:serviceURL" 
keyVaIue="dvb://1.2.a7> 

3 0 <keyedReference tModelKey="uddj:tv-record.org:serviceURL" 

keyValue="dvb://1.2.b7> 
<keyedReference tModeIKey="uddi:tv-record.org:serviceURL" 

keyValue="dvb://1 .2.c7> 
</categoryBag> 
3 5 </bindingTemplate> 
</save_blnding> 
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The <accessPoint> element provides the HTTP address 
of the recorder to which the "suhmit^Data" request must 
be sent. 

The <instanceParnis> element contains the declaration 
5 of what may be expected of the recorder (content of the 
data structure <TV_Record_Service_Declaration> defined 
for the first embodiment) which defines the transcoding, 
bit rate production and transfer protocol capabilities, 
the list of recordable broadcast channels and the 
10 charging policy. 

The <categoryBag> element contains a list of the 
broadcast channels that the recorder is able to record - 

2.2 Discovering a network recorder using a web 
service . 

15 The technology of web services and of UDDI 

(Universal Description, Discovery and Integration) 
services in particular also offers terminals the option, 
if they have an Internet connection, of discovering 
broadcast audiovisual content recorders by consulting the 

20 directory, without necessitating any prior knowledge. 
Thus any terminal can use a node of the UDDI 
business directory (which has well known addresses) to 
find broadcast individual content recorders using the 
<find_hinding> command as shown below: 

25 

<find_bincling xmlns="um:uddi-org:api_v3''> 
<tModelBag> 

<tModelKey>uddi:tv-reoord.org:submit_Data_v10</tModelKey> 
</tModelBag> 
3 0 <categoryBag> 

<keyedReference tModelKey="uddi:tv-reoord.org:serviceURL** 

keyValue="dvb://1.2.a7> 
<keyedReference tModelKey="uddi:tv-record.org:serviceURL" 
keyValue=''dvb://1.2.c7> 
3 5 </categoryBag> 
</find_blnding> 
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In this example, the terminal is looking for a 
network recorder for the channels or television channels 
"dvb://1.2.a" and "dvb : /I . 2 . c" . 

In response, the terminal receives a 
<bindingTemplate> list that matches its request (recorded 
in the directory of services by the command 
<save_jbinding>) . 

2-3 Requesting recording in the network 

After choosing an audiovisual content recorder, the 
terminal can send the following request using the SOAP 
(Simple Object Access Protocol) to request the recording 
of a content (the request encapsulating the 
<TV_Record_Service_Request> request defined in the 
preceding embodiment) : 

POST /Wr/md-service HTTP/1 .0 
Host: www.voila.fr 

Content-Type: text/xml; charset="utf-8" 

Content-Length: nnnn 
Accept-Encoding: deflate 
SOAPAction: "submit^Data" 

<?xml version="1.0" encoding="UTF-8''?> 
<Envelope xmlns=*' http://schemas.xm lsoap.orgysoap/enveloper> 
<Body> 

<submit_Data xmlns="http://www.tv-record.org/2002/1 1/transport"> 
<TV_Record_Service_Request 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:noNamespaceSchemaLocation="TVRecServ.xsd" userld="XcGHJ63DX"> 
<RequestedTransferProtocol>FTP</RequestedTransferProtocol> 
<Transcodlng>MPEG-4</Transcodlng> 
<MaxBitRate>1 500</MaxBltRate> 
<Contentldentification crid="crid://hbc.com/foxes/episode1 1" 
serviceURL="dvb:// 1.4ee2.3f5r 

start="2001 -04-07T1 9:00:00.00+01 :00" duration="PT1 H30M7> 
<Contentldentlfication crid="crid://ch1 ,com/serie/ep12" 
serviceURL="dvb://1 .4ee2.3f4:4f5r 
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start="2003-06-27T12:30:00.00+01:00''duration=-PT0H30M" 
instanceMetadatald="iml:broadcast/17> 
</TV_Record_Service_Request> 
</submit_Data> 
</Body> 
</Envelope> 

In return the terminal receives the following 
response for recording requests that have succeeded and 
other recording requests that have failed: 

HTTP/1.1 200 OK 

Content-Type: text/xml; charset="utf-8" 
Content-Length: nnnn 
Content-Encoding: deflate 

<?xml verslon="1.0" encoding=''UTF-8"?> 
<Envelope xmlns="http://www.w3.org/2002/06/soap-envelope''> 
<Body> 

<submlt_Data_Result xmlns='* http://schemas.xmlsoap.org/soap/envelope/"> 
<TV_Record_Servjce_Req u est_Response 

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsj:noNamespaceSchemaLocatjon=TVRecServ.xsd'*> 
<RecordRequestSuccess crid=''crid://h bc.com/foxes/episode1 V 
requestld="12456XD34- 

recordEndTime="2003-04-07T20:30:00.00+01:007> 
<RecordReque5tSuccess crid="crid://zzz.com/movie/titler 
requestld="156WQ77" 

reoordEndTime="2003-04-07T20:30:00.00+01:00" 
l<eepDuration="PT24H" recordCost="2'' cun-ency=''USD7> 
<RecordRequestFailure crid="crid://ch1 .com/serie/ep12" 

KOreason="unl<nownCRID7> 
<RecordRequestFatiure crid='*crid://chaine5.com/film1 5" 
KOreason='*unavailabteServiceURL7> 
</TV_Record_Service_Request_Response> 
</submit_Data_Resutt> 
</Body> 



SUBSTITUTE SPECIFICATION 3 3 



</Envelope> 

The same procedure is used to encapsulate other 
requests defined in the preceding embodiment for other 
steps of recording audiovisual content in the network. 



